Mobile communication is constantly making progress. A typical scenario or environment in relation to a scenario to which some aspects of the present invention are applicable, is for example a scenario as applied in conjunction with e.g. a user equipment UE that is enabled to communicate via multiple access systems, e.g. via a radio access network such as LTE (Long Term Evolution) operating in a licensed band and an alternative access system such as WLAN (Wideband Local Area Network) operating in an unlicensed band.
Note that the number of access systems is not limited to two but may be more than two. Also, more than one of the access systems may operate in a licensed band (licensed in the sense that it is reserved for such access system), or may operate in an unlicensed band (also referred to as shared band) (unlicensed or shared in the sense that plural access systems may access such band or bands, e.g. the ISM band (Industrial Scientific Medical)). Note that typically, an access system is a wireless access system but need not be limited to a wireless access system. In case of a wireless access system, typically a radio access system based on a certain radio access technology (RAT) may be encompassed. Though, other non-radio based wireless access systems may be encompassed as well, such as infrared or Bluetooth™ or Zigbee™.
Examples of a RAT comprise aforementioned LTE, or LTE-Advanced (LTE-A), but may also comprise UMTS (Universal Mobile Telecommunication System), GSM (Global Standard of Mobile Communication), GPRS (General Packet Radio Service), or the like in addition to e.g. WLAN (WiFi™) etc.
A terminal may be embodied by a so-called user equipment UE or mobile station MS or a smartphone or tablet device.
According to some aspects, in such communication scenarios, a network entity such as an access point AP (representing e.g. a WLAN access system) and/or a network transceiver device such as an evolved NodeB, eNB (representing e.g. a LTE access system and/or a (part of) a radio access network thereof (correspondingly represented by a NodeB in a UMTS RAN or a base station BS in a GSM RAN), communicates via control and payload (e.g. data or voice) channels with the terminal such as a user equipment UE.
The recent growth in data traffic driven by mobile applications on those smartphone devices, tablets, etc. has continued to strain the capacity of today's networks. Therefore, network operators are increasingly utilizing un-licensed WiFi™ or WLAN spectrum to cope with such network congestion, and this trend is expected to accelerate further as traffic demand continues to grow.
The use of unlicensed spectrum is a cost-effective means to add the needed capacity to today's networks, given the limited availability and high cost of the licensed spectrum.
Currently, WLAN is integrated as a separate access network (or access system) to the 3GPP EPC (3rd Generation Partnership Project Evolved Packet Core). This requires extra cost of deploying the complete WLAN access network and also impacts the 3GPP core network entities. Existing WLAN offload solutions are based on this deployment model of distinct 3GPP and WLAN access networks/systems using a common core with selective switching of flows based on operator and/or user policies. Other solutions are possible that result in a tighter integration and aggregation of 3GPP access network components with WLAN access networks without any impact to and reusing the same 3GPP core network elements.
Recently, a discussion was initiated to extend the same design principles already defined for carrier aggregation (CA) to support aggregation/coordination of cells/carriers across Wide and Local Area Networks as well. E.g. a study item referred to as “WLAN/3GPP Radio Interworking” is defined so as to evaluate LTE-WLAN and UTRA-WLAN interworking procedures while improving seamless and non-seamless mobility.
3GPP defined Access Network Discovery and Selection Function (ANDSF). This defines a client-server relationship between a client on a mobile device (e.g. UE or MS) and a centralized server. The interface that is used to exchange ANDSF information between client and server is called the S14 interface and it is defined over the IP layer (Internet Protocol). The exchange of information leading to a new client policy can be triggered by a client pull (client request) or a server push (server providing). The initial client pull occurs after the device establishes a connection, e.g. a cellular connection. The client (at the UE) provides its location information and requests a WiFi policy. A client pull also occurs when the client's device moves to another predefined location zone.
In either case, the WiFi Control Module (i.e. the server) accesses a multi-dimensional set of data (representing one or more policies) to assist in making the policy decision. These parameters include location, time, network conditions, subscriber entitlements, and charging/billing usage information. The WiFi Control Module (server) can also push an unsolicited policy to the client (UE) under certain configurable conditions, such as an increase in network utilization, a specific usage threshold exceeded, a change in subscriber entitlement or a change in time of day.
FIG. 5A illustrates an example of such policies maintained in an ANDSF server/client and referred to as Inter System Routing Policy ISRP. In that FIG. 5 distinct policies are illustrated in terms of their respective traffic description, assigned priority, preferred radios, i.e. access system to be used and respective forbidden radios (access systems) according to such policy.
Currently, the ANDSF is generally considered useful and could be considered as basis for further RAN (Radio Access Network) enhancements. But probably, one can not assume that ANDSF is always available in reality. So, a general proposal is that the solution shall be consistent with ANDSF, but shall be also independent of its presence, i.e. shall work with and without ANDSF. Since ANDSF is stored in a server, it is only connected to a mobile device through a logic S14 interface, as shown in FIG. 5B; therefore it is transparent to the core network and radio network entities.
To avoid low WLAN utilization, a network operator might want some more network control such that the eNB is imparted the capability to “command” some terminals to make offloading to WLAN. Such offloading may be applied to the entire communication of the terminal (which may be assumed to be comprised of plural possibly simultaneous services such as speech, video, streaming/downloading data, etc.) or only to a part thereof, hence be applied service specific.
If ANDSF is available and eNB control for offloading is also enabled, one possible issue is that the ANDSF content is transparent (insofar unknown) to eNB. Hence, an eNB may make network control decisions which conflict with ANDSF policies since the eNB is not aware of it.
One straightforward solution is to enable the regular information sharing between ANDSF server and all eNBs in terms of ANDSF contents/policies. However, this requires fundamental change on ANDSF structural design, and core network structure change. Further, data traffic will increase and impose a burden on the network and its interfaces.
Therefore, there is a demand to consider solutions which assume the existing structure and which avoid such fundamental changes to become necessary.
A possible consequence of the mentioned issue is that the UE may be confused whether it should obey the RAN network control command (originating at a eNB), or to obey the ANDSF policies and correspondingly resulting commands.
In a way, the ANDSF reflects operator's general preference on some typical scenarios. For example, it may forbid some services to be used in WLAN in ANDSF to guarantee safe operation, but it may not be best solution in some specific scenarios. It may happen for some cell coverage for the terminal UE, that the eNB may find that the QoS (Quality of Service) can be sufficiently supported and better than LTE. There are also some cases where the ANDSF policy is not about QoS, but about security or other reasons, so that eNB may make wrong decisions if not following ANDSF policy.
Besides, if a terminal UE rejects the RAN network control command, the network might think the UE is not suitable for offloading, or experienced link failure, and this in turn might lead to a deteriorated network and UE performance in general.
Therefore, above outlined scenarios still present open issues and those are to be addressed with more efficient solutions. The potential conflict problem as outlined above is for example addressed in some contributions.
Namely, contribution R2-131441 only mentions the problem to be addressed, but does not offer a solution thereto.
Contribution R2-131366 mentions fixed priority of RAN commands over ANDSF policies in various UE connection states, and at most that “ANDSF policy should be provided to the RAN so that it can be taken into account when making mobility decisions” (at the RAN).
Further, according to one contribution (R2-130993) any conflict between commands is beforehand prevented in that the EUTRAN entity is made aware of the ANDSF policies and only provides commands to UE which are compatible to ANDSF policies/commands. In another contribution (R2-131265), conflicts are prevented in that eNB and ANDSF provide either different information, or information from either eNB or ANDSF is limited a priori by potentially conflicting information/commands and thus not provided to a UE, which will prevent a conflict at the UE.
Hence, there is still a need to further improve such systems.